Subject: DLSw ACTION ITEM: LF Size Propagation

From: [email-masked] (Paul Brittain)
Date: Thu, 30 Jun 94 17:32:33 BST

Connect RIGlet,

As promised, here is some feedback on Wayne Taylor's proposal for the
propagation of the LF bits through DLSw.  As Wayne's original note was issued
some time ago, I have appended a copy below to save you from having to search
through your mail filing system!

There seem to be no major issues with Wayne's proposal apart from the one
issue he raised himself (interaction with caches).  Fortunately this doesn't
appear to be difficult to solve as discussed below.

Cache Interaction Issue
=======================

As Wayne pointed out, if an implementation caches the route to a locally
accessible MAC or Name and uses this cache to speed the reply to CUR_ex/NNQ_ex
requests, there is a possibility that the cached route may not be available
when the CUR_cs is issued, and that any alternative route supports only a
smaller LF size.

If this does happen, it means that the bridge topology on the Target LAN has
changed for some reason, probably beacuse of loss of a link or bridge.  With
this mindset, it seems entirely appropriate to simply fail the circuit setup
attempt that has hit this problem and flush (or replace) the bad cache entry.

The most obvious and simple way to achieve this for the Target DLSw not to
issue the ICR_cs if the LF bits on the CUR_cs are incompatible with the route
it obtains.  However this does imply that if the Origin DLSw also uses a
cache to speed the reply to TEST frames without issuing a CUR_ex, it must
retain the LF bits from the ICR_ex for all time until it next fails to set up a
circuit using the cached data.  A CUR_ex must then be issued for the next TEST
frame to relearn the new LF bits (and location) of the cached MAC address.

This is slightly complex at first sight - but caching is still optional and if
you do use it you must be prepared to handle the complexities of relearning bad
cached data!  Hence this seems like a good general solution.  See the next
section for one further enhancement that we could also adopt.

Cache and XID3s
===============

If the Origin DLSw is aware that it is dealing with an SNA station that uses
XID3s (which will be the case if it is issuing the CUR_cs as a result of
receiving an XID3), it could avoid the failure of the circuit setup attempt by
modifying the XID3 max BTU size field.  However this requires that the Target
does not fail the circuit setup attempt if the LF bits don't match.

For this to be possible, let's use one of the reserved bits in Wayne's LF Size
field to mean "don't care if you return a smaller size".  If this bit, say the
top bit, is set, it instructs the Target DLSw to use the LF size specified
in the CUR_cs when issuing the TEST frame, but to return the ICR_cs with
whatever value is obtained for LF size even if it is smaller.  The Origin DLSw
is then responsible for deciding whether to drop the circuit by issuing
a HALT_DL_NOACK or to continue and issue the REACH_ACK.

This bit may also prove useful in the future for other DLC types where the
Origin DLSw can guarantee that the Origin end station will act on any LF size
returned on the ICR_cs.

Note that the Origin DLSw is not required to support this use of XID3s (or
other mechanisms for LF size propagation), but the Target DLSw is required
to implement the 2 lines of code needed to support this bit flag (in addition
to the LF Size field support).

Minor Issues and comments
=========================

1)      We should probably specify which SSP frames are required to carry this
        information.  This informations seems to make sense on CUR, ICR, NNQ,
        NNR, XIDFRAME, DATAFRAME and DGRMFRAME messages only.

2)      Wayne's example flows below include the use of a TEST cmd/rsp pair
        after the receipt of an ICR_cs.  This corresponds to how the 6611 (and
        RFC 1434) currently works but it is not required if the Origin DLSw has
        retained the RIF from the XID/NQ that initiaited the CUR_cs.

3)      I suggest we reverse the bit order (or the labelling of the bits!) to
        put the LF bits in the least-significant 6 bits of the byte as this is
        marginally earier to parse.

Documentation
=============

I suggest that we change the name of the reserved field in the control headers
as described by Wayne below, and add the bit-table (including modifications) &
list of valid SSP messages as a description of the new LF Size field thus:

        LF Size Field
        -------------

        The Largest Frame Size (LF Size) field in the SSP Control Header is
        used to carry the LF Size bits across the DLSw connection.  This should
        be used to ensure that the two end-stations always negotiate a frame
        size to be used on a circuit that does not require the Origin and
        Target DLSw partners to re-segment frames.

        This field is valid on CANUREACH_*, ICANREACH_*, NETBIOS_NQ_ex,
        NETBIOS_NR_ex, XIDFRAME, DATAFRAME and DGRMFRAME messages only.  The
        contents of this field should be ignored on all other frames.

        Every DLSw forwarding a SSP frame to its DLSw partner must ensure that
        the contents of this frame reflect the minimum capability of the route
        to its local end-station or any limit imposed by the DLSw itself.

        The bit-wise definition of this field is as follows:

            7   6   5   4   3   2   1   0
           --------------------------------
          | c | r | b | b | b | e | e | e |
           --------------------------------

            c   .   .   .   .   .   .   .  Origin DLSw "don't care" flag
                                           (significant on messages from
                                            Origin to Target DLSw only)

                                           0=fail circuit if route obtained
                                             requires a smaller LF size
                                           1=don't fail the circuit but return
                                             the LF size obtained even if it is
                                             smaller

            .   r   .   .   .   .   .   .  Reserved
            .   .   b   .   .   .   .   .  Largest Frame Bit Base
            .   .   .   b   .   .   .   .  Largest Frame Bit Base
            .   .   .   .   b   .   .   .  Largest Frame Bit Base
            .   .   .   .   .   e   .   .  Largest Frame Bit Extended
            .   .   .   .   .   .   e   .  Largest Frame Bit Extended
            .   .   .   .   .   .   .   e  Largest Frame Bit Extended

                    <----- LF Bits ----->

        Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame
        base and extended bit values.

        The Origin DLSw "don't care" flag informs a Target DLSw that chooses to
        reply to *_ex messages on the basis of cached information that it
        may safely return a smaller LF Size on the ICR_cs frame if it has had
        to choose an alternative route on which to initialize the circuit.  If
        this bit is set to 1, the Origin DLSw takes responsibility to ensure
        that the end-stations negotiate a suitable frame size for the circuit.
        If this bit is set to 0, the Target DLSw must not reply to the CUR_cs
        if it cannot obtain a route to the Target end station that support an
        LF Size at least as large as that specified in the CUR_cs frame.

         -----------------------------------------------

I have posted a separate note to Alan giving him just these updates without all
the other detail in this note so that he can incorporate somthing in the next
document release.  If you wish to propose further changes in the handling of LF
bits, please provide updated documentation too.

Wayne's note is appended below with comments (marked 'PB>') to relect the
suggestions  described above.  Please post any further comments you may have on
this subject - positive reinforcement is encouraged in place of absolute
silence!

Paul Brittain
Data Connection

Appended Mail:
==============

            _ _          _ _ _          _ _ _         _ _
          /     \       |     |        |     |      /     \
     W __|Bridged|______| 6611|________| 6611|_____|Bridged|__ Y
         |  NW   |      |  A  |        |  B  |     |  NW   |
          \ _ _ /       |_ _ _|        |_ _ _|      \ _ _ /
                         __|__          __|__
                         __|__          __|__
                         __|__          __|__
                       X __|__        Z __|__
                           |              |

Abbreviations
B    - Broadcast (ARE or STE)
ARE  - All Route Broadcast
STE  - Spanning Tree Explorer
SRF  - Specifically Routed Frame
LF   - Largest Frame
LFo  - Largest Frame Bits Origin
LFt  - Largest Frame Bits Target
LFn  - Largest Frame Bits Negotiated
LFao - Largest Frame Bits Adjusted by Origin DLSw
LFat - Largest Frame Bits Adjusted by Target DLSw
SSP  - Switch to Switch Protocol
MTU  - Maximum Transmission Unit

The LF bits would be defined in the SSP Control Message Reserved field
that follows the SSP Control Message Header Length field. This field
will be referenced as Largest Frame Size (LF Size). The definitions of
the bits in the LF Size field are as follows:

    0   1   2   3   4   5   6   7
   --------------------------------
  | r | r | b | b | b | e | e | e |
   --------------------------------

    r   .   .   .   .   .   .   .  Reserved
PB>
PB> let's use the top bit for the don't care flag thus:
PB>
PB> c   .   .   .   .   .   .   .  Origin DLSw "don't care" flag (significant
PB>                                on messages from Origin to Target DLSw only)
PB>
PB>                                0=fail circuit if route obtained requires
PB>                                  a smaller LF size
PB>                                1=don't fail the circuit but return the
PB>                                  LF size obtained even if it is smaller
PB>
    .   r   .   .   .   .   .   .  Reserved
    .   .   b   .   .   .   .   .  Largest Frame Bit Base
    .   .   .   b   .   .   .   .  Largest Frame Bit Base
    .   .   .   .   b   .   .   .  Largest Frame Bit Base
    .   .   .   .   .   e   .   .  Largest Frame Bit Extended
    .   .   .   .   .   .   e   .  Largest Frame Bit Extended
    .   .   .   .   .   .   .   e  Largest Frame Bit Extended

            <----- LF Bits ----->

Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame
base and extended bit values.

Token Ring - Token Ring (SNA)

   STN W    Origin DLSw                 Target DLSw      STN Y

  TEST-c
 --------->          CANUREACH_ex
 B  LFo        --------------------------->      TEST-c
                         LFao                   ---------->    Note 1
                                                B  LFao

                                                  TEST-r
                                                <----------
                      ICANREACH_ex                 LFt
               <---------------------------                    Note 2
   TEST-r                 LFat
 <----------
    LFat

  XID-c
 --------->          CANUREACH_cs
 SRF LFn       --------------------------->      TEST-c
                         LFn                    ---------->    Note 3
                                                B  LFn

                                                  TEST-r
                                                <----------
                      ICANREACH_cs                 LFt
               <---------------------------                    Note 4
   TEST-c                 LFat
 <----------
    B  LFat

   TEST -r
 ----------->
    LFo
                       REACH_ACK
                --------------------------->

                       XIDFRAME
                --------------------------->

NOTE 1:
A TEST frame (broadcast) generates the new explorer CANUREACH
in the origin DLSw. The origin DLSw should adjust the LF bits to the size
of the largest frame it can receive (LFao). This adjusted LF value is
included in the CANUREACH. The target DLSw responds to the CANUREACH with
the new ICANREACH explorer message if the target station is reachable
through the target DLSw. The target DLSw should adjust the LF bits that
are included in the ICANREACH to the largest frame it can receive (LFat).

Note 2:
The origin DLSw responds to the origin station TEST-c. The LF bits in
the TEST-r would be set to the adjusted target LF (LFat) that were in the
ICANREACH.

Note 3:
The first non-broadcast frame is received by the origin DLSw so a
CANUREACH_cs circuit-setup message is sent. The LF bits in the
non-broadcast frame would be included in the CANUREACH circuit-setup
message. The LF bits are included in the circuit setup message, because
implementations may choose to cache information at different times during
connection setup.

Note 4:
Upon receipt of the ICANREACH_cs message, the origin DLSw creates a link
station. The ICANREACH_cs message includes the LF bits of the target
station (LFt). The target DLSw DLC implementation may not require the
TEST-c/TEST-r exchange to create a link station.

However, there is problem with this approach if the target DLSw cache
entry for the target station has been deleted or changed before the
CANUREACH_cs message is received from a given origin station. If the
target DLSw has to perform a TEST-c/TEST-r exchange when the CANUREACH_cs
message is received, there is a chance the LF bit value in the route
obtained are less than the LF value in the CANUREACH_cs message. This
could result in frames being discarded (assuming DLSw does not segment).
Furthermore, sending the LF bits from the obtained route back to the
origin DLSw in the ICANREACH_cs doesn't help because the origin station
has already selected the route it plans to use. I am still thinking
throught this problem. Any suggestions, ideas ??

PB> Depending on the setting of the "don't care" bit, either drop this circuit
PB> setup attempt (i.e. don't issue the ICR_cs), or return the new LF size on
PB> the ICR_cs.

Token Ring - Token Ring (NETBIOS)

   STN W    Origin DLSw                 Target DLSw      STN Y

 Name Query
 --------->         NETBIOS_NQ_ex
 STE  LFo      --------------------------->     Name Query
                         LFao                   ---------->    Note 1
                                                STE  LFao

                                                 Name Recognized
                                                <----------
                    NETBIOS_NR_ex                 SRF  LFt
               <---------------------------
  Name Recognized         LFat
 <----------
   SRF  LFat

   SABME
 --------->          CANUREACH_cs
  SRF  LFn     --------------------------->      TEST-c
                         LFn                    ---------->    Note 2
                                                 B  LFn
     UA
 <---------                                       TEST-r
   SRF LFn                                      <----------
                      ICANREACH_cs                 LFt
               <---------------------------                    Note 3
   TEST-c                 LFat
 <----------
    B  LFat

   TEST -r
 ----------->
    LFo

     UA
<-----------
   SRF LFo
Note 1:
A NETBIOS NAME_QUERY generates the new explorer NETBIOS_NQ_ex
in the origin DLSw partner.  The target DLSw sends out the
NETBIOS NAME_QUERY contained in the NETBIOS_NQ. The origin DLSw adjusts
the LF bits to the size of the largest frame it can receive (LFao).

Note 2:
The first non-broadcast frame is received by origin partner so
a circuit-setup CANUREACH is sent.  It would be up the the
implementation to decide whether to acknowledge the SABME
immediately or wait until the ICANREACH is received.
The CANUREACH_cs causes a DLC_START_DL in the target partner,
resulting in a TEST frame exchange. A DLC implementation that does not
a TEST-c/TEST-r exchange could just respond with the ICANREACH.
The target station LF bits (LFt) are returned in the ICANREACH.

Note 3:
Upon receipt of the ICANREACH_cs the origin partner starts a
link station instance.  An implementation may optionally send a
TEST-c/Test-r exchange to create a link station.

Token Ring - Ethernet (SNA)

   STN W    Origin DLSw                 Target DLSw      STN Z

  TEST-c
 --------->          CANUREACH_ex
 B  LFo        --------------------------->      TEST-c
                         LFao                   ---------->    Note 1

                                                  TEST-r
                                                <----------
                      ICANREACH_ex
               <---------------------------                    Note 2
   TEST-r                 LFat
 <----------
    LFat

  XID-c
 --------->          CANUREACH_cs
 SRF  LFn      --------------------------->      TEST-c
                         LFn                    ---------->    Note 3

                                                  TEST-r
                                                <----------
                      ICANREACH_cs
               <---------------------------                    Note 4
   TEST-c                 LFt
 <----------
    B  LFt

   TEST -r
 ----------->
    LFo

Note 1:
A TEST frame (broadcast) generates the new explorer CANUREACH
in the origin DLSw. The LF bits included in the CANUREACH are adjusted
by the origin DLSw to the largest frame it can receive (LFat).
If the target DLSw has cached information about the target station, it
it responds with the new ICANREACH explorer message. Because the target
DLSw does not know the origin station is on a token ring media
the LF bits in the ICANREACH are adjusted to a value less than or equal
to the MTU size of the ethernet port where the TEST-r was received.
The LF value closest to the Ethernet MTU can be computed using the
largest integer value equation defined in IEEE 802.1d Standard, Annex C.
This would require the DLSw to have a table of the base LF values as
defined in the standard.

Note 2:
The origin DLSw reponds to the TEST frame with the LF bits set to
the value of LF of the target station (LFt). The origin station should
honor the value of the LF bit settings.

Note 3:
The first non-broadcast frame is received by the origin DLSw so
CANUREACH_cs circuit-setup message is sent. The LF bits in the RI
field of the non-broadcast frame is included in the circuit setup message
(LFo). The LF bits are included in the circuit setup message, because
some implementations may choose to cache information about the target
station during circuit-setup exchange rather than target explorer
exchange. The target DLSw DLC implementation may not require the
TEST-c/TEST-r exchange.

Note 4:
Upon receipt of the ICANREACH_cs message, the origin DLSw creates a link
station. The ICANREACH_cs message includes the LF bits of the target
station (LFt). The target LF bits (LFt) are derived and required as
stated in Note 1. The target DLSw DLC implementation may not require the
TEST-c/TEST-r exchange to create a link station.

Ethernet - Token Ring(SNA)

If the connection attempt is initiated from the Ethernet end station, the
LF bits for the SSP messages would be derived as stated in Note 1 for
the Token Ring - Ethernet scenario.

Token Ring - Ethernet / Ethernet - Token Ring (NETBIOS)

The NetBios flows for Token Ring to Token Ring apply for Token Ring -
Ethernet, except the derivation of the LF bits are as stated in Note 1
of the Token Ring - Ethernet (SNA).

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Thu, 30 Jun 94 17:33:37 PDT

Hi,
1. The don't fail bit sounds like a good idea.
2. I do not see a need for the 3 extended bits.
   We could work with just 3 bits like all SRB bridges do,
   in the sense that all the intermediate switches keep reducing it to
   their comfort levels along the route.
3. I would like to devote 1 bit for the ARE/STR indication
4. And, one bit to indicate that this CUR is due to a Test or XID.
5. About adjusting the max BTU for XID3 it will work ok only for PU2.1
   devices with a caveat for devices generating XID0.

             7   6   5   4   3   2   1   0
            --------------------------------
           | c | r | b | b | b | x | y | r |
            --------------------------------

c   - fail(0) / don't fail(1) bit
bbb - LF bits
x   - ARE(0)  / STE(1) indicator.
y   - Test(0) / XID(1) indicator
r   - reserved

What do you think?
	/pandian

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +